GenericFormDataValidator<TModel> is a (currently undocumented) convenience abstract class for implementing IFormDataValidator. The benefit is that HasRelevantChanges and ValidateFormData has a signature of TModel instead of object and the helper method CreateValidationIssue that takes an expression (aka linq) instead of providing the field the issue relates to as a string. In addition ValidateFormData does not return a list of issues, but instead you register them with AddValidationIssue and CreateValidationIssue.

The previous version of this abstract class defined the DataType property and to ensure that users actually set this property, it was a required parameter in the constructor. Today I realised that it was hard to read and understand how that magic string ended up in the base() call, and that an abstract class can declare an abstract property so that inheriting classes is required to implement the property. I think this results in much prettier code.

// Define constructor in order to set `DataType` to a hard coded value
public TestValidator() : base("MyType"){}

The new way is almost the same as when you implement the IFormDataValidator interface directly (needs the override keyword because of the abstract class)

// Just override the property (as required by the compiler) and set the value directly.
public override string DataType => "MyType";

Breaking change, alternatives?

This is a breaking change which will cause those apps that has started to use GenericFormDataValidator<TModel>. As it is not documented, I think that would be very few cases.

Add obsolete message, to better explain the change

We can improve the error message by adding the following constructors.

    /// <summary>
    /// Default constructor
    /// </summary>
    public GenericFormDataValidator() { }

    [Obsolete("Override DataType instead of setting in constructor `public override string DataType => \"MyType\";`", error: true)]
    public GenericFormDataValidator(string dataType) { }

Create a new abstract class

As this is just a utility class, we could potentially just add a new one with a new name and the slightly changed semantics. This will ensure that no direct changes will be needed until the old (obsolete) version is removed in v9. Good suggestions for names would be very welcome. See suggestion here

Related Issue(s)

• New validation extension #369

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)